New, in REALbasic 5.5, is the ability to create service applications using REALbasic.
* What is a service application?
A service application is a special type of console application that is meant to run whether there are no users logged in. This means your application should not require any user interaction with a user (since it's entirely possible that no user is logged in while your application is running). Typical examples of services would be FTP servers, HTTP servers, and other types of UI-less servers.
* What program design principles are different than with a console application?
Console applications rely on Print and Input for communicating with the user. Services behave much the same (depending on how the service is installed, and on what operating system). For example, if your service is run as a daemon on Mac OS X or Linux by using the inet.d scripts, then print and input will actually correspond to a socket that the system has already attached for you. This means that .Write will actually behave just like a socket and .Read will as well.
It is worth noting that this behavior is not guaranteed for all operating systems. If you plan on deploying your service on multiple OSes, it is best to use a TCPSocket directly instead of relying on the standard input and output being hooked up to a socket for you.
* So how do I make a service application?
In order to create a service application, you must first create a regular console application. Once you have your console application, you will see that you have a single project item called "App" whose super is ConsoleApplication. Change App's super to being a ServiceApplication, and you're set!
* What is the ServiceApplication class, and what events does it have?
The ServiceApplication class is a subclass of ConsoleApplication class, so all the standard ConsoleApplication events and methods apply. In addition to the ConsoleApplication's events, there are three new events for a service application. Some of these events will only be fired on operating systems that support them (and the only OS that supports them currently is Windows). Here are the events and a brief explanation of when they will be fired.
Pause()
This event gets fired when the user selects "pause" from the Service Control Manager on Windows. When the user selects pause, they expect your service to stop performing whatever action it was doing. It should continue to halt execution until the Continue event is called.
Continue()
This event gets fired after the user has selected "continue" from the Service Control Manager on Windows. You will never get a Continue event unless you've already gotten a Pause event. The user expects your application to resume its actions after this event has been called.
Stop( shuttingDown as Boolean )
This event gets fired for two reasons. One is when the user clicks "stop" from the Service Control Manager on Windows. If they have selected that, then shuttingDown will be false. The other way to get this event is when the computer is shutting down (in which case shuttingDown will be true). This event will get called when you call Quit for any platform, or when the service terminates (see note below about service termination). Note that the shuttingDown parameter is only supported on Windows.
Run( args() as String )
This event gets fired just like a regular console application. It means that your service is being started up. This event will occur on all platforms.
* Is there anything I should know that may be different from platform to platform? (Note: this is all about service termination!)
Well, aside from the fact that Pause and Continue will not be called on anything but Windows, there is one more chunk of Windows weirdness. Exiting the run method will _not_ terminate your application if it is a service on Windows. This is because the Windows Service Control Manager is responsible for determining when your application should quit. On other platforms, this is not the case (since they are essentially just scripts that start the execution of your application). If you want to be sure your application will terminate when exiting the Run event, call Quit just before the event terminates. This will cause a Stop event to occur on all platforms as well (and ensure that your application behaves the same across platforms).
